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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by by the Joint Technical Committee (JTC) Broadcast of the 
European Broadcasting Union (EBU), Comite Europeen de Normalisation Electrotechnique (CENELEC) and the 
European Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, EN 300 401 [1], for DAB (see note) which now has worldwide acceptance. The members of the 
Eureka Project 147 are drawn from broadcasting organizations and telecommunication providers together with 
companies from the professional and consumer electronics industry. 

NOTE: DAB is a registered trademark owned by one of the Eureka Project 147 partners. 



Introduction 



The present document is one of a set associated with DAB. EN 300 401 [1] describes the transmitted signal, the 
interface between the broadcaster's transmitters and the listener's receiver. The associated documents, EN 300 797 [2], 
EN 300 798 [3] and ETS 300 799 [4] describe additional interfaces, which can be used by broadcasters or network 
providers to build DAB collection and distribution networks. In particular the document EN 300 797 [2] establishes a 
standard way for transporting Service Components, Service Information and control messages between two entities in a 
DAB collection network. Because of the openness and flexibility of the Service Transport Interface (STI) standard there 
is uncertainty regarding the implementation of it. This applies to interoperability between devices from different 
suppliers. Practical broadcast scenarios do not always require to implement the full standard, which creates the problem 
that different suppliers might implement different subsets of EN 300 797 [2]. 

To overcome this problem and to fully exploit the great potential of the DAB system, the subject of the present 
document is to describe implementation levels of the STI standard and to outline their usage. 
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Scope 



The present document establishes guidance in implementation and usage of the functionality described in the STI 
standard EN 300 797 [2]. Subsets of the STI standard are defined in order to make interoperable solutions possible for 
different suppliers of STI devices. The subsets are called STI Levels. Interoperability is ensured if the STI Logical 
Interface (LI) and STI Physical Interfaces (STI-PI, X) are the same for entities transporting DAB Service Components, 
Service Information and control messages in a DAB collection network. The present document only particularizes the 
Logical Interface (LI) layer of the STI, i.e. the syntax for STI-D frames and STI-C messages, to provide 
interoperability. 

The present document defines a functional hierarchy of levels. Higher levels comprise lower levels. Three levels are 
specified where the highest STI Level does not comprise all STI functionality that could be implemented using 
EN 300 797 [2]. Some of the functionality is not included due to the fact that it is not assumed to be widely used. This 
functionality may optionally be added to any of the defined STI Levels. 

The present document defines the minimum functionality an upstream or downstream entity shall provide on each level 
to be considered compliant with that level. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[1] ETSI EN 300 401 (VL3.2): "Radio broadcasting systems; Digital Audio Broadcasting (DAB) to 

mobile, portable and fixed receivers". 

[2] ETSI EN 300 797 (VLLl): "Digital Audio Broadcasting (DAB); Distribution interfaces; Service 

Transport Interface (STI)". 

[3] ETSI EN 300 798 (VLLl): "Digital Audio Broadcasting (DAB); Distribution interfaces; Digital 

baseband In-phase and Quadrature (DIQ) interface". 

[4] ETSI ETS 300 799 (1997): "Digital Audio Broadcasting (DAB); Distribution interfaces; Ensemble 

Transport Interface (ETI)". 

[5] ETSI TR 101 496 (all parts): "Digital Audio Broadcasting (DAB); Guidelines and rules for 

implementation and operation". 

[6] ITU-T Recommendation G.704: "Synchronous frame structures used at 1544, 6312, 2048, 8448 

and 44 736 kbit/s hierarchical levels". 

[7] ITU-T Recommendation G.703: "Physical/electrical characteristics of hierarchical digital 

interfaces". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in EN 300 401 [1], EN 300 797 [2] and the 
following apply: 

STI Level: Subset of functionality according to EN 300 797. 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in EN 300 401 [1], EN 300 797 [2] and the following 
abbreviations apply: 



API 

DNS 

EP 

lANA 

IP 

ISDN 

SP 

TCP 

VPN 



Application Programming Interface 

Dynamic Name Server 

Ensemble Provider 

Internet Assigned Numbers Association 

Internet Protocol 

Integrated Services Digital Network 

Service Provider 

Transport Control Protocol 

Virtual Private Network 
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STI Levels 



The STI Levels describe the STI functionality, i.e. STI-D stream types and STI-C message sets and their usage, that STI 
entities shall provide to be considered STI level compliant. The levels shall be subsets of EN 300 797 [2] with respect to 
STI-D(LI) and STI-C(LI) functionahty. 

A total of three levels is defined. The level requiring the least functionality is called level 1 . Higher levels shall fully 
comprise the lower ones. The levelling proposed in the present document is only valid for the logical part of 
EN 300 797 [2] and does not apply to physical interfaces. Thus an STI capable device may be equipped with one or 
more physical interfaces, each being capable of providing one of the STI Levels as defined in the present document. 



4.1 STI-D(LI) Stream Types 



The STI-D(LI) data stream types classified in EN 300 797 [2], clause 4.2, are divided into two parts, basic stream types 
and optional stream types. 



4.1 .1 Basic Stream Types 



Basic stream types are: 

MSC sub-channel audio stream service component; 

MSC sub-channel data stream service component; 

MSC sub-channel data stream made of one or more packet mode service components (and padding); 

FIC FIG stream Service Information; 

FIC FIG stream Fast Information Data Channel service component. 
Table 1 shows which TID and TIDext shall be supported. 

Table 1 : TID/TIDext supported as basic stream types 



TID 


TIDext 


Significance 






1 
2 


MSC audio stream 

MSC data stream 

MSC packet mode stream 


4 



1 


Service Information 
FIDC 



4.1.1.1 



MSC sub-channel streams 



The basic stream types shall provide correct handling of individual MSC streams as described in EN 300 797 [2], 
clause 5.9.1. 



4.1.1.2 



FIC FIG stream 



The basic stream types shall provide correct handling of FIC FIG streams carried in STI-D(LI) as described in 
EN 300 797 [2], clause 5.9.3. 
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4.1 .2 Optional Stream Types 

Other stream types than those defined as basic are optional on all STI Levels: 
MSC sub-channel contribution packet mode data service component; 
FIC FIG stream CA information; 
FIC FIB stream asynchronous FIB insertion; 
FIC FIB stream synchronous FIB insertion. 

4.2 STI Level 1 

This clause defines the minimum functionality required by an STI upstream or downstream entity to be considered 
conformant to STI Level 1 . Only STI-D(LI) basic stream types are supported. Control message exchange between 
upstream and downstream entities is not included. Therefore no support of STI-C(LI) messages is required. Usage of 
this level shall assume a configuration agreement between the upstream and downstream entities. 

4.2.1 STI-D(LI) requirements 

All basic stream types as defined in clause 4.1.1 shall be supported in downstream entities. At least one basic stream 
type shall be supported in upstream entities. 

The handling of FIGs carrying DAB logical frame count information (see EN 300 401 [1]) needs not be supported in 
FIC FIG streams. 

4.2.2 STI-C(LI) requirements 

In STI Level 1 no setup and control messages can be exchanged between an upstream and downstream entity. Therefore 
no support of STI-C(LI) shall be required. 

4.3 STI Level 2 

This clause defines the minimum functionality required by an STI upstream or downstream entity to be considered 
conformant to STI Level 2. The minimum functionality required in level 1 shall be comprised on this level. On STI 
Level 2 the possibility to exchange certain STI-C(LI) messages between upstream and downstream entities shall be 
supported. Extending the functionality provided on STI Level 1, STI Level 2 supports seemless and coordinated 
dynamic reconfiguration as well as the usage of FIG files. 

4.3.1 STI-D(LI) requirements 

The STI-D(LI) requirements of STI Level 1 shall be comprised, i.e. all basic stream types as defined in clause 4.1.1 
shall be supported in downstream entities. At least one basic stream type shall be supported in upstream entities. 

The handling of FIGs carrying DAB logical frame count information (see EN 300 401 [1]) needs not be supported in 
FIC FIG streams. 
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4.3.2 STI-C(LI) requirements 



In STI Level 2 exchange of control messages shall be supported. The required functionality comprises seamless 
dynamic reconfiguration of the DAB multiplex initiated by the upstream entity, the possibility to define new 
configurations, exchange of error messages and frame counter information. FIG files in addition to FIG streams may be 
used to provide FIC content. Therefore the following message classes, as defined in EN 300 797 [2], shall be supported: 

Action messages, i.e. message class ACTION; 

Configuration messages, i.e. message class CONFIG; 

FIG file messages, i.e. message class FIGFILE; 

Information messages, i.e. message class INFORMATION; 

Supervision messages, i.e. message class SUPERVISION. 

NOTE: Only the reconfiguration initiation by the upstream entity shall be mandatory. The possibility of 

reconfiguration enforcement on upstream entities from the downstream entity shall be an option. This 
means, that not the complete functionality of message class ACTION shall be required (see also 
annex A). 

4.4 STI Level 3 

This clause defines the minimum functionality required by an STI upstream or downstream entity to be considered 
conformant to STI Level 3. The minimum functionality required on the lower levels shall be comprised on this level. 
Extending the functionality provided on STI Level 2, STI Level 3 supports the possibility to exchange STI-C(LI) 
messages of the RESOURCE class between upstream and downstream entities. 



4.4.1 STI-D(LI) requirements 



The STI-D(LI) requirements of STI Levels 1 and 2 shall be comprised, i.e. all basic stream types as defined in 
clause 4. LI shall be supported in downstream entities. At least one basic stream type shall be supported in upstream 
entities. 

The handling of FIGs carrying DAB logical frame count information (see EN 300 401 [1]) needs not be supported in 
FIC FIG streams. 

4.4.2 STI-C(LI) requirements 

In STI Level 3 exchange of control messages shall be supported. The STI-C(LI) requirements of STI Levels 1 and 2 
shall be comprised. STI Level 3 shall also handle scarce DAB resources. Therefore the following message class, as 
defined in EN 300 797 [2], shall be supported: 

Resource messages, i.e. message class RESOURCE. 

NOTE: MSC sub-channel packet mode data contribution is an option. Therefore the PACKCON message does 
not need to be supported. 

4.5 Connecting entities of different STI Levels 

The present document describes three levels of functionality when using EN 300 797 [2]. Because of the hierarchical 
definition of levels, lower levels have limitations that must be considered when connecting entities of different STI 
Levels. These limitations are listed in table 2. 
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Table 2: Functional limitations of the STI Levels 



STI 
Level 


Limitation 


1 


- co-ordination of dynamic reconfiguration is not supported 

- only asynchronous SI insertion is possible 


2 


- DAB ensemble resource co-ordination based on RESOURCE 
messages is not supported 


3 


- reconfiguration enforcement on an upstream entity by a 
downstream entity is not supported 

- FIG FIB streams are not supported 

- FIG FIG stream GA are not supported 

- FIB grids are not supported 

- IVISC packet mode data contribution is not supported 

- handling of FIGs carrying DAB logical frame count information, for 
example paging FIG 5/0 (see EN 300 401 [1]) 

- handling of GA FIGs 


NOTE: Limitations listed on a higher level also apply to lower levels. 



When using STI Level 1 or 2 on an STI connection, the upstream and downstream entity shall agree on the following 
items to be able to use the full functionality of these STI Levels: 

transmission channel capacity that the upstream entity can use; 

streams that the upstream entity is entitled to use; 

identifiers that the upstream entity is entitled to use; 

FIGs that the upstream entity is entitled to use; 

announcement parameters that the upstream entity is entitled to use. 
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Annex A (informative): 

Implications of STI level definitions on device functionality 



A.1 Introduction 



This annex gives guidance in using the STI Levels defined in chapter 4 of the present document to achieve functional 
interoperability of STI devices. 

A DAB collection network has a hierarchical tree structure as given in EN 300 797 [2] clause 4.4.2, figure 7, by a 
representative example. Figure A. 1.1 repeats this network example, outlining the different roles STI devices can play in 
such a network. The roles are: 

1) Ensemble Provider: EP 

The Ensemble Provider device, e.g. ensemble multiplexer, always forms the root entity of a DAB collection 
network; 

2) Service Provider (upstream entity): SP^e 

A Service Provider device, which has only STI outputs, forms a leaf entity in the DAB collection network; 

3) Service Provider (upstream and downstream entity): SPpg/y^ 

A Service Provider device having both STI inputs and outputs forms an intermediate entity in the DAB 
collection network. It has passing and processing functionality with respect to STI. 



SPt, 



SPt, 




SPt 



SPt 



-Leaf entity 



SPr 




-Intermediate entity 



-Root entity 



Figure A.1.1 : Tree structure of the hierarchical DAB collection network 

As defined in EN 300 797 [2], each entity is uniquely identified by either SPID or EPID. 

Each single input or output of a device shall be characterized by the STI Level it can process or generate. An STI 
connection between an output (upstream entity of the STI connection) of one device and an input (downstream entity of 
the STI connection) of another device can then be characterized by the resulting STI Level, which is the lower level of 
the two involved. 

In order not to loose functionality or even information on the path from a leaf to the root entity, the following relation 
should be kept for each connection in the path. 

The upstream entity's STI Level should be lower than or equal to the downstream entity's STI Level to be able to use the 
upstream entity's complete functionality. In case an upstream entity with an STI Level higher than the downstream 
entity's is used on an STI connection, the upstream entity shall expect to receive PRERROR UKN messages as defined 
in EN 300 797 [2] when issuing messages which are not part of the downstream entity's STI Level. 

NOTE: Clause A.2 describes the different roles in the network in detail and outlines their implications on STI 
functionality and the interoperability aspects. 
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A.2 Minimum STI device functionality 



A.2.1 Ensemble Provider (EP) 



The Ensemble Provider defines the possible range of functionalities in a DAB collection network. These may include 
decentralized control and signalling, DAB resource control and consistency checking. The Ensemble Provider 
dynamically generates the resulting DAB multiplex signal. 

The most important EP functions are (in the context of an STI based collection network): 

a) processing of all basic stream types as defined in clause 4.1.1; 

b) the EP defines the exact time instant for execution of a multiplex reconfiguration and provides control data 
needed by its upstream entities to support the reconfiguration according to EN 300 797 [2]; 

c) so-called hst FIGs as defined in EN 300 401 [1] and TR 101 496 [5] shall be detected from FIG files and 
processed accordingly. For instance regarding FIGs 0/6, 9, 11, 13, 18, 21, 22, 23, 24, 25, 27 additional signalling 
of Service Information Version/Change Event Indication (SIV/CEI) shall be implemented; 

d) in case that STI based resource co-ordination shall be supported in the collection network, it is primarily up to 
the EP to define resources (both transmission and coding resources) and to provide consistency checks to make 
sure that its upstream entities cannot interfere with one another. 

A.2. 1.1 STI Level 1 

a) STI-D(LI) implications: 

All basic STI-D stream types shall be processed according to the local configuration of the respective EP entity 
(see b). 

b) STI-C(LI) impHcations: 

No STI-C connection exists, which implies that specification of (re-)configuration shall be done by some other 
means, for instance by a (proprietary) local API or user interface. 

Optionally this may also comprise local generation of Service Information to be signalled in addition or 
alternatively to FIG stream(s) contained in STI-D. 

c) General network implications: 

restricted solution; 

no communication between EP and SP via STI-C; 

DAB collection network operation is co-ordinated without use of STI. 

A.2. 1.2 STI Level 2 

a) STI-D(LI) implications: 

All basic STI-D stream types shall be processed according to configuration information exchanged via STI-C 
and thus extending the STI Level 1 functionality. Coordinated, seamless, dynamic reconfiguration based on 
current/next configuration as negotiated via STI-C between EP and SP shall be implemented. 

b) STI-C(LI) implications: 

An STI-C connection shall be available providing the subset of messages according to the STI Level 2 
definition. This implies that the specification/reception of configurations and the acceptance of dynamic 
reconfigurations via STI-C shall be implemented (procedure as described in EN 300 797 [2], annex E). The 
possibility of the downstream entity enforcing a reconfiguration on the upstream entity is not mandatory. When 
connected to an STI Level conformant upstream entity, an EP should not issue an RCONFIG DEE message 
without prior reception of RCONFIG REQ from the upstream entity. The latter mechanism may only be used in 
case it is agreed between the entities in addition to the STI Levels. 

Additionally complete support of FIG file usage (USEFIGF and FIGFILE messages as defined in 
EN 300 797 [2] as well as the respective FIG processing) shall be implemented. 
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c) General network implication: 



STI Level 2 provides an STI solution essentially based on bi-directional communication between the EPand 
directly connected SPs via STI-C; 

network operation can be remotely controlled to a certain extent by SPs, supported by STI; 

no co-ordination of ensemble resources (coding and transmission capacity) is supported via STI on this level. 

A.2.1.3 STI Level 3 

a) STI-D(LI) implications: 

In addition to STI Level 2, resources (FIC capacity and identifiers) used in SI delivered via FIG streams shall be 
supervised by the EP, based on resource allocations available for all of its upstream entities and the EP itself (see 
b) below). 
In practice this means at least the following: 

1) checking of FIG type consistency to TIDext of FIG stream; 

2) blocking of FIGs (type/extension) which are MCI FIGs or marked in FIGBLCK messages; 

3) no further check if 'Other Ensemble' flag is set in FIG; 

4) to avoid interference between SPs the use of the following sensitive FIG data shall be checked with regard to 
allocated resources to the respective SP: 

Service Identifiers (Sid): in FIG 0/13, 16, 17, 18, 23, 25, 27 and FIG 1/1, 4, 5 

Component Identifiers (SubChId or FIDCId or SCId): in FIG 0/5, 20 and FIG 5/0, 1 , 2 

Linkage set parameters (LSN and S/H and ILS): in FIG 0/6 
Announcement provision parameters referring to: 

a) the LP's ensemble (Clusterld and Asw and SubChId): in FIG 0/19 

b) another ensemble or FM/RDS (Clusterld and Asw): in FIG 0/26, 28 

FIGs that do not pass these checks shall not be transmitted in the FIC. An FIG content error message shall be 
generated using the STERROR DEE message as defined in EN 300 797 [2] with the ErrType field set to "C". If 
the allocated mean FIC capacity of an SP is exceeded, the EP may reduce the FIG repetition rates of the respec- 
tive SP. The EP should inform the SP by sending an error message using STERROR DEE with the ErrType field 
set to "I". 

b) STI-C(LI) implications: 

In addition to STI level 2, ensemble resource allocation (as defined in EN 300 797 [2]) to all directly connected 
upstream entities shall be provided. The respective specifications shall be supported by a (proprietary) local API 
or user interface. 

On request, the EP is obliged to send complete information about resources allocated to an upstream entity using 
a resource data exchange session. The EP shall give notification to the upstream entity in case of a change in 
resource allocation using a resource data exchange session. Configurations and FIG files shall be checked 
against the allocated resources taking into account their time of activation. 

c) General network implications: 

full communication between EP and SP via STI-C; 

network operation and use of ensemble resources can be fully co-ordinated as far as supported by 
EN 300 797 [2] and STI Level 3. 
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A.2.2 Service Provider (SP) 

Important SP functions are (in the context of an STI based collection network): 

a) multiplex of service component data (audio, packet mode or stream mode data channels) and mapping into 
STI-D (synchronous process, fixed frame relation); 

b) multiplex of service signalling and FIDC data (FIG streams) and mapping into STI-D (asynchronous process, no 
fixed frame relation); 

c) specification and activation of configurations and FIG files (if STI Level >1); 

d) acting on behalf of subordinate SPs (for SP£,£/u£). 

A.2.2. 1 Service Provider (upstream entity) 
A.2.2.1.1 STI LeveM 

a) STI-D(LI) implications: 

At least one of the basic STI-D stream types shall be generated according to a local configuration definable via a 
local API or user interface. If one or more FIG streams are generated to provide for static and/or dynamic 
Service Information then cyclic repetition of FIGs shall be accomplished according to TR 101 496 [5] (including 
SIV/CEI if respective FIGs are submitted). Care should be taken that limitations of bit rates and allocated FIC 
capacity are not exceeded. 

b) STI-C(LI) implications: 

No STI-C connection exists, which implies that neither specification and activation of MSC (re-)configuration 
nor use of FIG files is possible by the respective SPs using the STI. Also no error or information messages can 
be received. 



A.2.2.1.2 STI Level 2 

a) STI-D(LI) implications: 

There shall be no difference from STI Level 1 concerning the supported stream types. In addition, seamless 
dynamic reconfiguration shall be supported, which requires the STI-D(LI) to dynamically adapt its content to the 
configurations negotiated via STI-C (see b) below). 

b) STI-C(LI) implications: 

An STI-C connection shall be available, providing the subset of messages according to the STI Level 2 
definition. This implies that specification and activation of dynamic reconfigurations via STI-C shall be 
implemented (procedure as described in EN 300 797 [2], annex E). In addition support of FIG file usage 
(USEFIGF and FIGFILE messages as defined in EN 300 3797 [1] as well as the respective FIG processing) shall 
be implemented. 

Information requests and basic error information are supported via STI-C using the message set allocated to this 
STI Level. 



A.2.2.1.3 STI Level 3 

a) STI-D(LI) implications: 

In addition to STI level 2, resource allocations received from a downstream entity via STI-C shall be respected in 
generation of STI-D(LI). STI-D(LI) streams shall be generated in accordance to the capacity limits defined by 
the downstream entity using the CHANCAP and STLIMIT messages. The content of FIG streams shall only use 
the resources defined by the downstream entity using the ID ALLOC, IDLIMIT and ANNSEND messages. 

b) STI-C(LI) implications: 

In addition to STI level 2, resource allocations received from a downstream entity via STI-C shall be respected. 
The extended information and error message set according to STI level 3 shall be supported. 



£75/ 



16 ETSI TS 101 860 VI. 1.1 (2001-12) 

A.2.2.2 Service Provider (downstream and upstream entity) 

According to clause A.2.1 intermediate entities are possible which are SP devices supporting STI inputs (as downstream 
entity) and one STI output (as upstream entity). Such devices have to fulfill additional tasks concerning the mapping 
between the STI input connections (in general multiple) and the single STI output connection, depending on the 
respective STI Levels involved. All implications concerning upstream entity Service Providers that were stated in 
A. 2. 2.1 shall also be valid for Service Providers (downstream and upstream). This clause describes additional 
implications specific to the combined downstream and upstream role. 

A.2.2.2. 1 STI Level 1 (downstream entity) 

For a Service Provider device with STI Level 1 at the downstream entity side any of the STI Levels 1 to 3 can be used 
at the upstream entity side: 

a) STI-D(LI) implications: 

All basic STI-D stream types shall be processed according to the local configuration (see b) below); 

b) STI-C(LI) implications: 

No STI-C connection exists, which implies that specification of (re-) configurations shall be done by some other 
means, for instance by a (proprietary) local API or user interface. 



A.2.2.2.2 STI Level 2 (downstream entity) 

For a Service Provider device with STI Level 2 at the downstream entity side STI Levels 2 or 3 can be used at the 
upstream entity side: 

a) STI-D(LI) implications: 

All basic STI-D stream types shall be processed and mapped into the STI-D output stream according to 
configuration information exchanged via STI-C and thus extending the STI Level 1 functionality; 

b) STI-C(LI) implications: 

An STI-C connection shall be available providing the subset of messages according to the STI Level 2 
definition. This implies that the specification/reception of configurations and the acceptance of dynamic 
reconfigurations via STI-C shall be implemented (procedure as described in EN 300 797 [2], annex E). The 
possibility of the downstream entity enforcing a reconfiguration on the upstream entity is not mandatory. When 
connected to an STI Level conformant upstream entity, an SPpg^yg should not issue an RCONFIG DEF message 

without prior reception of RCONFIG REQ from the upstream entity. The latter mechanism may only be used in 

case it is agreed between the entities in addition to the STI Levels. 

Additionally complete support of FIG file usage (USEFIGF and FIGFILE messages as defined in 

EN 300 797 [2] as well as the respective FIG processing) shall be implemented. 

NOTE: The support of dynamic reconfigurations implies a mapping to and from the upstream entity side of the 
device and coordination of the reconfiguration with the following downstream entity. 

A.2.2.2.3 STI Level 3 (downstream entity) 

For a Service Provider device with STI Level 3 at the downstream entity side STI Level 3 can be used at the upstream 
entity side: 

a) STI-D(LI) implications: 

In addition to STI Level 2, resources should be supervised by the SP^g/yg, based on resource allocations 
available for all of its upstream entities and the SPj-jg^^g (see b) below); 
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b) STI-C(LI) implications: 

In addition to STI level 2, resources allocated at a downstream entity shall be shared between the upstream 
direction SPs and the SP^g^g device. The respective specifications shall be supported by a (proprietary) local 
API or user interface. 

On request, the SPq^/ue ^^^^^ send complete information about resources allocated to an upstream entity using a 
resource data exchange session. The SPq^/ue ^^^^^ 8^^^ notification to the SP in case of a change in resource 
allocation using a resource data exchange session. Configurations shall be checked against the allocated 
resources taking into account their time of activation. 
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Annex B (informative): 

Examples of DAB collection networks 

B.1 Introduction 

This annex shows some general examples on how STI devices can be used in DAB collection networks. 



B.2 Examples 
B.2.1 Example 1 



Non-STI Service Provider 



Ensemble Provider 







Non STI 
Device 
























Provider X 





Service Provider 







Service 
Mux 

UE:Level 1 
































Figure B.2. 1.1 : Example over DAB collection network 

Two Service Providers, one delivering a non-STI stream, the other delivering STI Level 1 , are connected to an 
ensemble multiplexer. 

The non-STI Provider's DAB conformant audio streams, including PAD, are inserted into the ETI signal generated by 
the ensemble multiplexer. All SI related to the non-STI streams is generated by the ensemble multiplexer. STI 
functionality cannot be used. 

As the other Service Provider delivers signals according to STI Level 1, the connection to the ensemble multiplexer is 
STI Level 1 based, irrespective of the ensemble multiplexer's STI Level. The lowest STI Level defines the useable 
functionality, in this example the upstream entity's STI Level 1 . 
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B.2.2 Example 2 
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Figure B.2.2. 1 : Example over DAB collection network 

This example shows that an upstream entity shall provide one or more STI-D stream types. A downstream entity shall 
be able of processing all basic stream types. 



B.2.3 Example 3 
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Figure B.2.3. 1 : Example over DAB collection network 

The provider Aj service multiplexer generates an STI-D stream. Provider Aj is able to use all features described in STI 
Level 1 . The provider A2 service multiplexer receives this stream and inserts it into its STI-D stream output. Provider 
A2 is able to use the whole functionality of STI Level 2. 

This example shows that the lower STI Level defines the usable functionality between two entities. 



£75/ 



20 



ETSI TS 101 860 VI. 1.1 (2001-12) 



B.2.4 Example 4 
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Figure B.2.4.1 : Example over DAB collection network 

The difference between examples 3 and 4 is the higher STI Levels of the service multiplexers. 

The provider A^ service multiplexer is able to use the functionality of STI Level 2, i.e. it is possible for provider Aj to 
reconfigure its Services. The SP receives feedback concerning its actions via the STI-C channel. 

The provider A2 service multiplexer is able to use the functionality of STI Level 3, i.e. it can use the RESOURCE 
messages. 
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B.2.5 Example 5 
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Figure B.2.5. 1 : Example over DAB collection network 

This example shows part of a typical STI network. 

It is possible that a downstream entity has inputs with different STI Levels. In this example each input of the ensemble 
multiplexer has an STI Level reflecting the STI Level of the corresponding service multiplexer's output. 
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Annex C (normative): 

Using TCP/IP as Transport IVIechanism for STI-C(LI) 

messages 

C.1 Introduction 

The STI-C(TA) transport adaptation is conceptually very close to TCP/IP. Hence STI-C(LI) message transport that uses 
standard TCP/IP instead of STI specific transport adaptation can be defined. TCP/IP may be used as a complete, 
bi-directional STI control part connection. 

This annex gives details on how TCP/IP shall be used for the transport of STI-C(LI) messages. 



C.2 IVIotivation and Background 
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Figure C.2.1 : STI-C using the STI-C(TA) over G.704 [6] or G.703 [7] 

An alternative to STI-C transport via STI(PI, X) is to use TCP/IP and replace the STI-C(TA) and underlying layers with 
TCP/IP. The TCP protocol contains re-transmit functionality and message counting, and the TCP layer therefore 
replaces the STI-C(TA) layer. 
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Figure C.2.2: STI-C using TCP/IP 

The STI-C(LI) messages are character-based messages defined in EN 300 797 [2]. 

The implementation of STI-C transport via TCP/IP shall be based on sockets and uses two connections for each 
bi-directional STI-C link. More than one upstream entity could be handled in the standard way of handing over to 
another TCP port during the phase of connection establishment. The downstream entity shall identify the respective 
upstream entity by its IP-address or DNS-name. 

NOTE ON SECURITY: 

There are several ways to achieve a higher level of security using encryption and authentication. 

a) a proprietary LAN with no connection to the outside world. An analog modem or ISDN could be used to bridge 
long distances; 

b) a VPN (Virtual Private Network) could also be used. Hardware as well as Software solutions are available on the 
market. 
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Each encryption type should use a unique port. 

A simple solution from an interoperability viewpoint is to use a VPN with an external hardware box on the Ethernet 
link. All STI-C(LI) messages will be tunnelled through the encryption modules on each side and the sending and 
receiving software will not notice any difference. 

There are also software solutions that will insert the VPN module into the TCP/IP protocol stack. 

The encryption and authentication algorithms are not part of the STI-C specification. The VPN solution does not affect 
the DAB application since there are solutions that use external equipment. 



C.3 Specification 



NOTE: Port 1076 is defined formally by reservation for "DAB STI-C" at Internet Assigned Numbers Association 
(IAN A), see also RFC 1700. 

STI-C over TCP/IP is using port 1076 as default port with the semantics and syntax of STI-C(LI) messages specified in 
the standard. Other port numbers may also be used instead of the default. 

Between two entities there shall be two TCP connections, each one used unidirectionally. The connection initiated by 
one entity shall only transport data from this entity to the other entity. 

The connection may be initiated either by the upstream or the downstream entity. 



:entitY 1 entity 2 

<<Connect>> to port 1 076 



Connection for entity 1 
to entity 2 is established 



Figure C.3.1 : The connection scheme 

If several upstream entities shall connect to the same downstream entity, the downstream entity shall distinguish the 
different entities by their IP addresses. STI entities making use of STI-C(LI) via TCP/IP shall be able to define a 
one-to-one mapping between the IP address/DNS-name and the Service Provider Identifier (SPID) or the Ensemble 
Provider Identifier (EPID). 
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